OSL – strengths and limitations

[Fredrik Averpil]

I haven't had much time to dig into OSL and what the capabilities / limitations are... but I'm reading that the next Renderman (19) will have support for it and Blender's Cycles already has it. If I'm not wrong V-Ray 3 will also have some support for OSL: http://docs.chaosgroup.com/display/VRAY3MAYA/VRayMtlOSL

So, let's play with the idea that you would want to create a generic shader (such as the VrayMtl) in OSL, to be used in all of these OSL capable renderers... is that even a realistic idea?
I'm talking a versatile material which could be used to create glass, metals, plastics etc. Or would it be better to create a series of very specific OSL shaders, rather than going for a generic one?
Would it even be possible to make the same shader work the same way / look the same in multiple renderers?

What are the biggest hurdles and problems to overcome if this is what you're trying to do?
And what possible drawbacks are you going to face (especially interesting to know with V-Ray+OSL)?

Does anyone have any good reading to recommend on OSL and writing OSL shaders?
I'm already reading the language specification: https://github.com/imageworks/OpenSh...nguagespec.pdf

[vlado]

I haven't had much time to dig into OSL and what the capabilities / limitations are... but I'm reading that the next Renderman (19) will have support for it and Blender's Cycles already has it. If I'm not wrong V-Ray 3 will also have some support for OSL: http://docs.chaosgroup.com/display/VRAY3MAYA/VRayMtlOSL

Yes, we already have our initial OSL support included for the next beta.

So, let's play with the idea that you would want to create a generic shader (such as the VrayMtl) in OSL, to be used in all of these OSL capable renderers... is that even a realistic idea? I'm talking a versatile material which could be used to create glass, metals, plastics etc.

You can get quite far with this; in fact one of our developers posted an OSL shader that implements a large part of the functionality of the VRayMtl material.

Or would it be better to create a series of very specific OSL shaders, rather than going for a generic one?

This I don't know... you'll have to try and see how it goes.

Would it even be possible to make the same shader work the same way / look the same in multiple renderers?

To some extent it is possible, especially for texture shaders. However most renderers define their own extensions which are generally not portable. I suppose it is currently a bit like Alembic in the beginning where everyone does their own thing. F.e. many OSL shaders for Blender will run in Blender only.

Best regards,
Vlado

[Fredrik Averpil]

Yes, we already have our initial OSL support included for the next beta.

This is awesome!
I downloaded the latest v3 nightly, gave it a go and emailed support because I stumbled upon an include error

You can get quite far with this; in fact one of our developers posted an OSL shader that implements a large part of the functionality of the VRayMtl material.

So basically, the black magic VrayMtl secret shading sauce math is exposed in it?
Where was it posted?
I would be interested in taking a look to learn and understand OSL in V-Ray better.

If OSL catches on, I think it would be very nice if you would consider keeping a github repo with official V-Ray OSL shaders, and possibly accept user submissions (although not supported or endorsed by Chaosgroup). It would be much better than bundling a couple of example shaders with the installation.

To some extent it is possible, especially for texture shaders. However most renderers define their own extensions which are generally not portable. I suppose it is currently a bit like Alembic in the beginning where everyone does their own thing. F.e. many OSL shaders for Blender will run in Blender only.

That is understandable. What extensions may that be in the case of V-Ray?

[ivaylo.ivanov]

You can check this page if you haven't.:
https://docs.chaosgroup.com/display/...pport+in+V-Ray
It's linked from the Maya help also, but in not very vsible way. Probably it's better to just copy it in the Maya help also.

[Fredrik Averpil]

Hi Ivaylo,
Yes I did. Those are great starting points. I thought Vlado meant that there was a far more complex OSL shader posted somewhere.

[RockinAkin]

Hi Ivaylo,
Yes I did. Those are great starting points. I thought Vlado meant that there was a far more complex OSL shader posted somewhere.

I know of this one only - http://forums.chaosgroup.com/showthr...432#post593432

[vlado]

Where was it posted?

See here: http://forums.chaosgroup.com/showthr...432#post593432

Best regards,
Vlado

[Fredrik Averpil]

Ah, thank you!

[Fredrik Averpil]

Hi again,

In the OSL example in your 3dsmax help, I found this example OSL shader:

surface vray_glass
(
    float eta = 1.44
)
{
    Ci = reflection(N, eta) + refraction(N, eta, "auto", 1);
}

In the refraction closure statement, what is "auto" and what is 1?
This is not mentioned under "Supported OSL Closures". Here it just says:

closure color reflection(normal N, float eta)

...as if there were no other supported attributes.


Are the closures following any standard where I should be looking up these things?`
When I searched the Open Language Specification PDF I did not find anything that would explain what "auto" and 1 would correspond to.

[Ivan Mavrov]

OSL closures provide a keyword extension mechanism that allows OSL implementations to stick to the specification and yet provide custom control.
However, these additional parameters are not guaranteed to be portable across other OSL hosts.

Yes the closures are following a standard and it is the Open Shading Language specification.
The OSL help section states what we support and additionally define:
Supported OSL Closures

You can find a description of the additional keyword arguments for the supported closures in the next section of the help index:
Additional Closure Arguments

You can find what keyword arguments each closure supports and a short description of what they do. Again these are V-Ray specific.

In this particular case the refraction closure supports:
float glossiness;
int subdivs;
int auto;

Description of "auto":

Use a value of 1 to allow V-Ray to take care of back face hits of refractive surfaces. Exit eta corrections and total internal reflections are done automatically. Default value is 0.

This means we can call a refraction closure in V-Ray like so:

refraction(N, eta, "auto", 1)

or why not even

refraction(N, eta, "auto", 1, "glossiness", 0.76)

Hope this clears things out.

Best regards,
Ivan Mavrov

[Fredrik Averpil]

Ah, perfect. It was a clear case of RTFM. Thank you!

[sharktacos]

I know of this one only - http://forums.chaosgroup.com/showthr...432#post593432

I tried this shader in Maya and noticed that the functionality to use a default color when the texture map is not present does not work and instead returns a black color. Is this working in Max?

[t.petrov]

Yes, it works in Max.
This functionality doesn't make too much sense in Maya, because
the exporter will always connect something to the texture inputs.
There is no mechanism to detect that nothing is connected to some parameter.

There is a plan to revisit the texture handling in the near future (hopefully 3.2),
because the current implementation is a bit awkward. In the future it should be
possible to connect a texture node to a color/float parameter and it should work
auto-magically.

[sharktacos]

From what I can see the code uses gettextureinfo to determine whether to use a texture or a color:

float getTextureFloat(string texture_name, float no_texture_default_value, float value_scale, float value_center_offset)
{
    int channels = -1;
    if (gettextureinfo(texture_name, "channels", channels))
    {
        color texture_sample = texture(texture_name, u, v);
        float sample_value = dot(vector(texture_sample), vector(0.3333333));
        float result = value_scale * sample_value + value_center_offset;
        return result;
    }

However in Maya this produces two parameters rather than one, so it has two opacity nodes for instance rather than one.

The larger issue however is that the current implementation of OSL in Maya defaults to black for a string (which needs to be used for texture maps rather than color) when it does not find a texture file. For something like opacity that means the shader is transparent by default. So I was hopeful the above code might be a way to get around that and supply default colors when it does not find a texture map.

What would really be ideal is if a float returned a slider (rather than a numeric input), and a color could have an input connection (from a texture or any other node in Maya) as you said.

[sharktacos]

There is no mechanism to detect that nothing is connected to some parameter.

how about gettextureinfo "exists" ?